Loading data into a mobile terminal

ABSTRACT

Disclosed is a method of loading data, such as software, into a mobile terminal, where the data is loaded from a loading station, and the data comprises payload data and header data. The mobile terminal accepts the data conditioned on a verification process based on the header data. The step of receiving the data further comprises the steps of receiving a header message including the header data from the loading station by the mobile terminal, verifying the received header data by the mobile terminal, and receiving at least a first payload message including the payload data, if the header data is verified successfully.

This invention relates to a method of loading data into a mobileterminal. The invention further relates to a system for loading datainto a mobile terminal. The invention further relates to a loadingstation and a mobile terminal for use in such a system.

Many mobile terminals, such as mobile phones or other mobile electronicequipment, comprise software and other data which are vital for theproper functioning of the mobile terminal. Hence, in order to maintainthe integrity of the mobile terminal, it is important that only approvedsoftware and data is loaded into the mobile terminal. For example, in aservice situation, the flash memory of a mobile terminal may be flashedin order to install or update the software controlling the mobileterminal.

U.S. Pat. No. 6,167,521 discloses a method of loading new code into alogical subregion of a device which is controlled by an authority.According to this prior art method, the authority prepares a messagecomprising the new code and certain parameters which specifyrequirements on the execution environment for the new code to run. Theauthority sends the generated message to the device which, upon receiptof the message, performs an authentication of the authority and verifieswhether the parameters are valid for the current execution environment.If yes, the device loads the received new code into the correspondinglogical subregion.

However, the above prior art method involves the problem that, if theverification fails, the complete message has to be retransmitted,thereby resulting in an inefficient method of loading software, inparticular, if the transmission is performed over a low bandwidthchannel or a noisy channel.

The above and other problems are solved when a method of loading datainto a mobile terminal, the method comprising the steps of

-   -   receiving the data from a loading station by the mobile        terminal, the data comprising payload data and header data; and    -   accepting the data by the mobile terminal conditioned on a        verification process based on the header data        is characterized in that the step of receiving the data further        comprises the steps of    -   receiving a header message including the header data from the        loading station by the mobile terminal;    -   verifying the received header data by the mobile terminal;    -   receiving at least a first payload message including the payload        data, if the header data is verified successfully.

Consequently, as the payload data is only received, if the verificationof the header data is successfully completed, the risk of receivingincorrect data is significantly reduced. Therefore, the loading processis more efficient as less re-transmissions of the payload occur.

It is a further advantage of the invention that it requires less storagespace in the mobile terminal, as no intermediate storage for the payloaddata is required during the verification process. This is a particularadvantage in devices with limited storage capacity, such as mobileterminals.

The payload data may be any type of data to be transmitted of the mobileterminal. The method according to the invention is particularlywell-suited for security sensitive data, for example software, softwareupdates or other program code means which control the operation of themobile terminal, as the receipt of incorrect software or process data,due to errors or an adversary, may cause the mobile terminal tomalfunction or to stop functioning at all. Examples of such softwareinclude application software and preloader software which is loadedprior to application software and which organises the download of theapplication software. Other examples of data include Internal RAM (IRAM)data, such as software which is directly loaded into the IRAM.

The header data may comprise version information, requirements on theexecution environment, such as types, manufacturers, and/or models ofcompatible mobile terminals, processors, chip sets, memories, etc.,types and/or versions of operating systems or other software alreadyinstalled in the mobile terminal, or the like. The header data mayfurther include a manufacturer identification, a software provideridentification, customer identification, or the like, access controllists, etc.

In a preferred embodiment of the invention, the header data comprises afirst cryptographic data item and the step of accepting the data by themobile terminal comprises the step of performing a cryptographicverification process based on the first cryptographic data item.Consequently, the authority issuing the payload data to be received maybe authenticated prior to the actual reception of the payload data,thereby further reducing the risk of erroneous transmission of payloaddata and increasing the efficiency of the method.

Preferably, the cryptographic data item includes a cryptographicchecksum where the term cryptographic checksum relates to a value whichis computed by the sender of a message, based on the data the messagecontains and a secret key, and passed along with the data to arecipient. Thus, the cryptographic checksum may be used by the recipientto authenticate that the data has not been tampered with. The recipientof the data recomputes the cryptographic checksum and compares it withthe cryptographic checksum passed with the data; if they match, therecipient may trust that the data was not tampered with duringtransmission. Hence, an important property of a cryptographic checksumis that without knowing the secret key, a malicious interceptor has onlyan infinitesimally small chance of being able to construct an alteredmessage with a valid corresponding checksum. For example, in order tocalculate a cryptographic checksum, a message digest of the message maybe calculated, e.g. by a one-way-hash function, which generates acondensed representation of the message where it is computationallyinfeasible to reproduce the message which corresponds to a given messagedigest, or to find two different messages which produce the same messagedigest. Any change to a message in transit will, with very highprobability, result in a different message digest, and the signaturewill fail to verify. Examples of such functions include the Secure HashAlgorithm (SHA-1), MD4 , MD5, or the like. Preferably, the resultingmessage digest is encrypted, or a signature is calculated for themessage digest, in order to generate the cryptographic checksum.Preferably, asymmetric, public-key based cryptographic methods such asthe RSA method developed by Ron Rivest, Adi Shamir, and Leonard Adleman,the Digital Signature Algorithm (DSA), or the like, are used.Alternatively, symmetric cryptographic methods such as MessageAuthentication Code (MAC) schemes may be used.

Signing/encrypting the message digest rather than the message oftenimproves the efficiency of the process, because the message digest isusually much smaller in size than the message.

Hence, the verification process may include, but is not limited to, averification of whether the execution environment of the mobile terminalis compatible with the parameters specified by the header data, averification of access control parameters, and a cryptographicverification based on the cryptographic data item, e.g. including anintegrity check and authentication of the origin of the header data.

It is an advantage of the invention that it provides protection againstunauthorised reprogramming of a mobile terminal.

In a further preferred embodiment, the payload data is divided into anumber of blocks of payload data, and the step of receiving the payloaddata further comprises the steps of receiving a number of payloadmessages each comprising one of the blocks of payload data; and storingin a storage medium each of the received number of blocks of payloaddata. Hence, as only one block of payload data is received at a time,the requirements for intermediate storage space in the mobile terminalare further reduced.

In another preferred embodiment of the invention, the payload data isprocessed prior to transmitting it to the mobile terminal. For example,the data may be encrypted in order to avoid interception and/or the datamay be compressed in order to reduce transmission time, bandwidthrequirements, requirements for the intermediate storage capacity at themobile terminal, and/or the complexity of the calculation of acryptographic checksum. Correspondingly, the method further comprisesthe step of processing the payload data conditioned on the step ofaccepting the data by the mobile terminal, e.g. uncompressing thecompressed data.

Furthermore, this is particularly advantageous, when the storage mediumis divided into a number of storage blocks each having a predeterminedsize; and each of the number of blocks of payload data have a block sizecorresponding to the size of storage blocks. An example of such memoryis flash memory, also called “flash RAM”, a type of constantly-powerednonvolatile memory that can be erased and reprogrammed in units ofmemory called blocks.

In a further preferred embodiment of the invention, the payload data isdivided into a number of blocks of payload data; the method furthercomprises the step of receiving a corresponding number of messagedigests related to respective ones of the number of blocks of payloaddata; the step of receiving the payload data further comprises the stepof receiving a number of payload messages each including one of thenumber of blocks of payload data; and the step of accepting the data bythe mobile terminal further comprises, for each of the number of blocksof payload data, the steps of

-   -   accepting the block of payload data by the mobile terminal        conditioned on a cryptographic verification process based on a        corresponding one of the message digests;    -   processing the accepted block of payload data;    -   storing the processed block of payload data in a storage medium.

Hence, instead of downloading the data unprocessed into the storagemedium, subsequently loading it into RAM, processing it, and storing itagain, the method according to this embodiment only requires one storageaction for each block of data, thereby increasing the efficiency of theloading process.

In a yet further preferred embodiment of the invention, thecryptographic verification process used in the step of accepting a firstblock of payload data received after a second block of payload data isfurther based on a result of a cryptographic verification process usedin a previous step of accepting the second block of payload data.Consequently, the cryptographic verification process is performedincrementally, where a message digest of a data block depends on all, orat least some of, the previous data blocks and/or their respectivemessage digests, thereby increasing the security of the loading process,as all data blocks are interconnected.

In yet another preferred embodiment of the invention, the payload datacomprises an update of existing data loaded in the mobile terminal; andthe method further comprises the step of only loading the blocks ofpayload data which differ from a corresponding block of the existingdata. Consequently, the amount of data to be transmitted may besignificantly reduced. For example, if the payload data comprises asoftware patch to an already installed software, the changes are oftenconfined to a small number of memory blocks. In this case, downloadingonly the effected blocks is considerably more efficient than downloadingan entire new version of the software.

In a preferred embodiment of the invention, the first cryptographic dataitem includes a first message digest encrypted with a private key of anauthority; and the step of accepting the data by the mobile terminalcomprises the steps of

-   -   calculating a second message digest of the received header data        and the received payload data;    -   decrypting the first message digest with a public key of said        authority; and    -   comparing the decrypted first message digest with the calculated        second message digest.

In another preferred embodiment of the invention, the header datafurther comprises a signed key to be used in the verification process bythe mobile terminal as a public key of the authority distributing thepayload data.

When the header data further comprises a second cryptographic data item,and the step of verifying the header data comprises the step ofperforming a cryptographic verification of the header data based on thesecond cryptographic data item, the security of the method is furtherincreased, as the header is checked separately.

The present invention can be implemented in different ways including themethods described above and in the following, a system, a computerprogram, a computer readable medium and various product means, eachyielding one or more of the benefits and advantages described inconnection with the first-mentioned method, and each having one or morepreferred embodiments corresponding to the preferred embodimentsdescribed in connection with the first-mentioned method.

It is noted that the features of the methods described above and in thefollowing may be implemented in software and carried out in a dataprocessing system or other processing means caused by the execution ofcomputer-executable instructions. The instructions may be program codemeans loaded in a memory, such as a RAM, from a storage medium or fromanother computer via a computer network. Alternatively, the describedfeatures may be implemented by hardwired circuitry instead of softwareor in combination with software.

The invention further relates to a method of uploading data into amobile terminal, the method comprising the step of transmitting the databy a loading station to the mobile terminal, the data comprising payloaddata and header data for use by the mobile terminal in a verificationprocess when accepting the data;

-   -   characterised in that the step of transmitting the data further        comprises the step of transmitting a header message including        the header data to be verified by the mobile terminal before        transmitting at least a first payload message including the        payload data, allowing the mobile terminal to reject reception        of the payload data.

In a preferred embodiment, the method further comprises the steps of

-   -   receiving a request from the mobile terminal for transmitting        the payload data; and    -   transmitting the payload data to the mobile terminal in response        to the received request.

Consequently, the payload data is only transmitted if the mobileterminal has acknowledged the receipt and successful verification of theheader data, thereby avoiding unnecessary transmission of payload data.

In another preferred embodiment, the method further comprises the stepsof

-   -   processing the payload data to be uploaded into the mobile        terminal;    -   generating a cryptographic data item for the processed payload        data; and    -   transmitting the cryptographic data item as a part of the header        data.

Hence, as the cryptographic data item is generated on the basis of theprocessed data, for example on the basis of compressed data, thereceiving mobile terminal may verify the data prior to furtherprocessing, e.g. decompressing, it, thereby increasing the efficiency ofthe method, as no unnecessary processing of incorrect data occurs at thereceiver.

The invention further relates to a system for loading data into a mobileterminal, the system comprising a loading station and the mobileterminal

-   -   the loading station including first transmitting means for        transmitting data to the mobile terminal, the data comprising        payload data and header data;    -   the mobile terminal including first receiving means for        receiving said data from the loading station; and    -   processing means adapted to accept the data conditioned on a        verification process based on the header data;        characterised in that    -   the loading station is adapted to transmit a header message        including the header data before transmitting the payload data;    -   the mobile terminal is adapted to receive the header message        from the loading station, to verify the received header data and        to cause the first receiving means to receive the payload data,        if the header data is verified successfully.

The term loading station comprises any electronic equipment includingcomputers, such as stationary and portable PCs, stationary and portableradio communication equipment.

The term mobile terminal comprises all portable radio communicationequipment and other handheld or portable devices. The term portableradio communication equipment includes all equipment such as mobiletelephones, pagers, communicators, i.e. electronic organisers, smartphones, personal digital assistants (PDAs), handheld computers, or thelike.

The terms receiving means and transmitting means include any suitablecommunications means, where the term communications means comprisescircuitry and/or devices suitable for enabling the communication of databetween the loading station and the mobile terminal, e.g. via a wired ora wireless data link. Examples of such communications means include anetwork interface, a network card, a radio transmitter/receiver, a cablemodem, a telephone modem, an Integrated Services Digital Network (ISDN)adapter, a Digital Subscriber Line (DSL) adapter, a satellitetransceiver, an Ethernet adapter, or the like. For example, the mobileterminal may be connected to a loading station via a wired connection orvia a short range wireless communications link using electromagneticsignals, such as infrared light, e.g. via an IrDa port, radio-basedcommunications, e.g. via Bluetooth transceivers, or the like. The datamay further be loaded over-the-air, i.e. via a radio interface of themobile terminal for connecting it to a wireless telecommunicationsnetwork, such as a Cellular Digital Packet Data (CDPD) network, a GlobalSystem for Mobile (GSM) network, a Code Division Multiple Access (CDMA)network, a Time Division Multiple Access Network (TDMA), a GeneralPacket Radio service (GPRS) network, a Third Generation network, such asa UMTS network, or the like.

The term processing means comprises general- or special-purposeprogrammable microprocessors, Digital signal Processors (DSP),Application Specific Integrated Circuits (ASIC), Programmable LogicArrays (PLA), Field Programmable Gate Arrays (FPGA), etc., or acombination thereof.

The invention further relates to a mobile terminal comprising

-   -   receiving means for receiving data from a loading station, the        data comprising payload data and header data; and    -   processing means adapted to accept the received data conditioned        on a verification process based on the header data;        characterised in that    -   the receiving means is further adapted to receive a header        message including the header data from the loading station; and    -   the processing means is further adapted to verify the received        header data; and to cause the receiving means to receive the        payload data if the header data is verified successfully.

The invention further relates to a loading station for uploading datainto a mobile terminal, the loading station comprising transmittingmeans for transmitting data to the mobile terminal, the data comprisingpayload data and header data for use by the mobile terminal in averification process when accepting the data;

-   -   characterised in that the transmitting means is further adapted        to transmit a header message including the header data to be        verified by the mobile terminal before transmitting the payload        data, allowing the mobile terminal to reject reception of the        payload data.

In a preferred embodiment, the loading station comprises

-   -   a first device including a secure memory for storing a private        key, and second processing means for generating a cryptographic        data item; and    -   a second device comprising second processing means for        generating the header data including the generated cryptographic        data item.

When the first device is a smart card, a secure memory is provided whichmay be removably connected with, e.g. inserted in, the second device,thereby allowing an easy and secure way of key management andconfiguration of the loading station.

The invention further relates to a computer program comprising programcode means adapted to perform, when running on a mobile terminal or aloading station, the steps of a respective one of the methods describedabove and in the following. The computer program may be embodied on acomputer-readable medium. The computer program may further be embodiedas a data signal on a carrier wave, e.g. as a data signal transmittedvia a communications network.

The terms storage medium and computer-readable medium comprise magnetictape, optical disc, digital video disk (DVD), compact disc (CD orCD-ROM), mini-disc, hard disk, floppy disk, ferro-electric memory,electrically erasable programmable read only memory (EEPROM), flashmemory, EPROM, read only memory (ROM), static random access memory(SRAM), dynamic random access memory (DRAM), synchronous dynamic randomaccess memory (SDRAM), ferromagnetic memory, optical storage, chargecoupled devices, smart cards, PCMCIA card, etc.

The invention will be explained more fully below in connection withpreferred embodiments and with reference to the drawings, in which:

FIG. 1 shows a block diagram of a system for loading data into a mobilestation;

FIG. 2 shows a block diagram of an example of a mobile station;

FIG. 3 illustrates a data format according to an embodiment of theinvention;

FIG. 4 illustrates a hierarchical key structure for use with anembodiment of the invention;

FIG. 5 shows a flow diagram of a method of loading data into a mobileterminal according to an embodiment of the invention;

FIG. 6 shows a block diagram of a system for loading data into a mobilestation according to an embodiment of the invention;

FIGS. 7 a-c illustrate examples of data formats according to anembodiment of the invention; and

FIGS. 8 a-b show flow diagrams of examples of a method of loading datainto a mobile terminal according to an embodiment of the invention.

FIG. 1 shows a block diagram of a system for loading data into a mobilestation. The system comprises a loading station 101 and a mobileterminal 105. The loading station comprises a storage medium 104 forstoring the payload data to be loaded into the mobile terminal,additional information to be transmitted to the mobile terminal asdescribed in connection with FIGS. 3, 7 a-b, one or more private keysfor calculating a cryptographic checksum, and/or other attributes foruse in the processing of the payload data. The loading station furthercomprises a processing unit 103 which is adapted, e.g. by softwareloaded from the storage medium 104, to process the payload data, e.g.compress and/or encrypt the payload data and/or divide it into blocks.The processing unit 103 is further adapted to generate header data,including the generation of one or more cryptographic checksums.Furthermore, the processing unit is adapted to control the transmissionof the header and payload data to the mobile station 105. The processingunit 103 may comprise a general- or special-purpose programmablemicroprocessor, Digital Signal Processor (DSP), Application SpecificIntegrated Circuit (ASIC), Programmable Logic Array (PLA), FieldProgrammable Gate Array (FPGA), etc., or a combination thereof. Theloading station further comprises a communications unit 102 comprisingcircuitry and/or devices suitable for enabling the loading station tocommunicate data with the mobile terminal via a wired or wirelesscommunications link 109 such as a direct data link, a communicationsnetwork, or the like. Examples of such communications units include anetwork interface, a network card, a radio transmitter/receiver, aBluetooth transceiver, an infrared port, an IrDa port, a cable modem, atelephone modem, an Integrated Services Digital Network (ISDN) adapter,a Digital Subscriber Line (DSL) adapter, a satellite transceiver, anEthernet adapter, or the like. Accordingly, the communications link 109may be a short-range wireless communications link using electromagneticwaves. Examples of such communications links include a Bluetoothconnection or another connection based on radio frequencies, infrared,microwave, or the like. The communications link may further be a wiredconnection, e.g. a serial connection, and USB connection, or the like.In yet another embodiment, the connection may be established via acommunications network, such as a local area network, a cellularnetwork, the Internet, or the like. The loading station 101 may furthercomprise a further interface 110, such as a network interface, a floppydisk drive, a CD drive, or the like, enabling the loading station toreceive payload data to be loaded into the loading station. The payloaddata may be received from a payload provider, e.g. a software provider,via a communications network, e.g. the Internet, or on a storage medium,such as a CD, a floppy disk, a memory card, or the like. The receivedpayload is stored on the storage medium 104, possibly after averification process and/or further processing. The loading station maybe a conventional, suitably programmed computer, e.g. a PC, comprising asuitable communications interface. A preferred embodiment of a loadingstation will be described in connection with FIG. 6.

In another embodiment, the loading station receives the payload data andthe header information from a remote computer, e.g. a personal computer,a work station, a network server, etc. For example, the data may bereceived via a computer network, e.g. the Internet, a local areanetwork, an intranet, an extranet, etc., or by any other suitable means,e.g. on a computer-readable medium such as a floppy disk, a CD ROM, etc.In this embodiment, the header generation, the calculation of messagedigests and the encryption are performed by the remote computer ratherthan the loading station. The loading station, e.g. a personal computer,performs, in cooperation with the mobile terminal, the loading of thedata into the mobile terminal, e.g. via a serial connection, an infraredport, a Bluetooth or other radio connection, or the like. Hence, in thisembodiment, the loading station only performs the tasks of initiallytransmitting the header information and, subsequently, transmitting thepayload data, preferably as individual blocks of payload data.

The mobile terminal 105 comprises a corresponding communications unit106 comprising circuitry and/or devices suitable for enabling the mobileterminal to communicate data with the loading station. The mobileterminal further comprises a processing unit 107, e.g. a general- orspecial-purpose programmable microprocessor, Digital Signal Processor(DSP), Application Specific Integrated Circuit (ASIC), ProgrammableLogic Array (PLA), Field Programmable Gate Array (FPGA), etc., or acombination thereof. The processing unit 107 is adapted, e.g. bysoftware loaded from the storage medium 108 of the mobile terminal, toreceive the header data and payload data from the loading station, toanalyse and verify the header information, and to load the payload datainto the storage medium 108. If applicable, the processing unit 107 isfurther adapted to process the payload data, e.g. uncompress or decryptit.

FIG. 2 shows a block diagram of an example of a mobile terminal. Themobile terminal 101 comprises a processing unit 107, as described above,for controlling the functions of the mobile terminal. The mobileterminal further comprises a radio interface 205 with an aerial 206 fortransmitting and receiving data to/from a wireless communicationsnetwork, e.g. a cellular network. The mobile terminal further comprisesa user interface 204, e.g. a display, such as an LCD, or the like, akeypad, or other input means, such as a touch screen, or the like. Theuser interface may be used during the loading process, if the loading iscombined with an interactive authentication/approval procedure whichrequires an input from the user, e.g. the entering of a password, a PIN,or the like. The mobile terminal may further comprise a subscriberidentity module (SIM) 207 including memory for storing subscriberidentity information, a telephone number, and other data related to auser's subscription with a cellular network operator. The mobileterminal further comprises a storage medium 108 which may comprise a RAMsection 203, a ROM section 202 and a section 201 comprising flashmemory. The payload data received from the mobile terminal may be loadedin the flash section and/or the RAM section of the memory. Alternativelyor additionally, the storage medium of the mobile terminal may compriseother types of memory, such as EPROM, EEPROM, or the like, or othertypes of storage media, such as optical disc, digital video disk (DVD),compact disc (CD or CD-ROM), mini-disc, hard disk, ferromagnetic memory,optical storage, charge coupled devices, PCMCIA cards, etc.Correspondingly, the payload data may be loaded in any of thealternative memory types and/or storage media. In one embodiment of theinvention, the payload data received from the loading station may beloaded into the memory of the SIM 207. Finally, the mobile terminalcomprises a communications unit 106 as described above, e.g. a Bluetoothtransceiver, an IrDa port, an USB adapter, a cable connector, or thelike. Alternatively, the radio interface 205 may be used to receive thedata over the air via a cellular network. For example, the mobileterminal may be any portable radio communication equipment, where theterm portable radio communication equipment includes all equipment suchas mobile telephones, pagers, communicators, i.e. electronic organisers,smart phones, personal digital assistants (PDAs), handheld computers, orthe like.

FIG. 3 illustrates a data format according to an embodiment of theinvention. The data comprises a header section 301 and a payload section302. The payload section 302 comprises the actual payload data to beloaded into the mobile terminal. The payload data may comprise software,such as application software, preloader software for organising and/orcontrolling the loading of other software, parts of the operating systemof the mobile terminal, or the like. Alternatively or additionally, thepayload data may comprise other data, e.g. data for storage into the RAMsection 203 of the mobile terminal, the SIM 207, or another type ofstorage medium in the mobile terminal. As will be described inconnection with FIGS. 7 a-b, the payload data may further be divided insmaller segments. The header section 301 comprises information about thepayload data, information about the mobile terminal, control parametersdetermining how the mobile terminal should process the data, andcryptographic information. According to the embodiment of FIG. 3, theheader data is split up in a manufacturer header 303 controlled by themanufacturer of the mobile terminal and a payload header 304 controlledby the provider of the payload. The manufacturer header 303 comprises acryptographic checksum (CCS) 303 a including a message digest encryptedwith a private key of the loading station. The cryptographic checksum303 a may be used by the receiving mobile terminal to verify theintegrity and authenticity of the header 301. The manufacturer headerfurther comprises hardware information 303 b, such as the type of chipset of the mobile terminal. The manufacturer header may further compriseinformation 303 c about the payload provider, such as a provider ID orthe like. It is understood that, alternatively or additionally, othertypes of information may be included in the manufacturer header. Forexample, the header may comprise a signed key for use by the mobileterminal during the subsequent verification of the payload. The payloadheader 304 comprises a cryptographic checksum 304 a for use by themobile terminal to verify the received payload data. The payload headerfurther comprises payload information 304 b, such as a software version,information about compatible types of mobile terminals, e.g. mobileterminals of predetermined manufacturers and/or predetermined models, orthe like. The payload header further comprises certificates 304 c, suchas one or more public keys for use by the mobile terminal during theverification of the current and/or future payloads. Furthermore, thepayload header 304 comprises destination information 304 d informing themobile terminal about where to load the received payload, e.g. in whichmemory section, at which address, etc. The payload header 304 furthercomprises a command section 304 e which may comprise access controllists, commands, load options, such as the type of compression used,whether the payload data should be stored contiguously, in individuallyaddressed areas of memory, or the like. It is understood that,alternatively or additionally, other types of information may beincluded in the payload header. It is further understood that anotherdivision of the header information may be used, including embodimentswhere the header 301 is not divided at all. The headers 303 and 304 maybe transmitted as one message or separately from each other. It isfurther understood, that the header may be further split up into smallerpackets prior to transmission according to the communications protocolused, e.g. by lower layers of the communications stack. Correspondingly,the header may be recombined at the receiver by the lower levels of thecommunications stack. According to the invention, at least the header303 is transmitted in a message prior to transmitting the payload. Thepayload header 304 may be generated by the payload provider and receivedby the loading station together with the payload data. Alternatively,the payload header may be generated by the loading station based oninformation provided by the payload provider.

FIG. 4 illustrates a hierarchical key structure for use with anembodiment of the invention. The security mechanism realises a chain oftrust. The mechanism provides control over the mobile terminal to themanufacturer of the mobile terminal, or another suitable authority.However, at the same time, the mechanism allows the delegation ofcontrol over what software or data may be loaded to one or more softwareproviders. The mechanism is based on public-key cryptography. A publicroot key 401 of the manufacturer is stored in the mobile terminal 105,e.g. in the ROM section 202 of the memory 108, in a special on-chipmemory of the processing unit 107, or the like. The root key 401 maythen be used to verify a public key 402 of a software provider to beinstalled in the mobile terminal 105, e.g. in the flash section 201 ofthe storage medium 108. The public key is encrypted or signed using aprivate key of the manufacturer which corresponds to the public root key401. When the encrypted public key 402 is received by the mobileterminal 105, e.g. as a part of the header data 301 or during a separateloading process, the public root key 401 is used to verify theauthenticity of the public key 402 before it is installed in the mobileterminal. Additionally, at each start-up of the mobile terminal, thepublic root key 401 may be used to verify the certificate of the publickey 402. Once installed, the public key 402 may subsequently be used toverify received payload data 403 which is signed with a correspondingprivate key of the software provider. Hence, according to thisembodiment, the software provider does not need access to themanufacturer's private key, and the manufacturer does not need access tothe private key of the software provider, in order to securely installthe software. Hence, it is an advantage of using a public key mechanismthat a hierarchical key structure may easily be implemented. It is afurther advantage of this embodiment that several public keys 402, e.g.corresponding to different payload providers may be installed in themobile terminal. Furthermore, the private root key corresponding to thepublic root key 401 is only used for encrypting or signing the publickey(s) 402 and not for signing the actual payload, thereby providing ahigh protection of the root key. It is noted that the above structuremay be extended, e.g. by introducing additional levels of keys.

FIG. 5 shows a flow diagram of a method of loading data into a mobileterminal according to an embodiment of the invention. In an initial step500, the loading station 101 prepares the payload. This step may includea compression of the payload in order to obtain a more efficienttransmission and a less complex calculation of cryptographic checksums.Alternatively or additionally, the loading station may encrypt thepayload in order to reduce the risk of an unauthorised interception ofthe payload during transmission. Subsequently, in step 501, the loadingstation generates header information including software information,requirements on the execution environment, etc. This step furtherincludes the calculation of one or more cryptographic checksums, e.g. amessage digest calculated over the header and encrypted with a privatekey of the loading station, or another cryptographic checksum. In thisstep any suitable cryptographic method for calculating a message digestmay be used, such as MD-5, SHA-1, or the like, preferably in combinationwith a public-key encryption method, such as RSA, DSA, or the like.Alternatively or additionally, the header may include a cryptographicchecksum calculated over both the header and the payload. In step 502,the generated header is transmitted to the mobile terminal. Afterreceiving the header in step 503, the mobile terminal verifies, in step504, whether the header information is correct. This verification mayinclude the checking of the cryptographic checksum over the header usinga public key stored in the mobile terminal. The verification process mayfurther comprise a verification of the software version, a comparison ofthe compatible execution environment with the execution environment ofthe mobile terminal, e.g. a comparison of CPU types, mobile terminaltype, operating system, or the like. If the header information is notverified successfully, the loading process is aborted, thereby avoidingan unnecessary transmission of incorrect software. In this case, anerror message may be sent to the loading station, possibly triggering are-transmission, e.g. with another software version, or the like. If theheader information is verified successfully, in step 505, the mobileterminal send a request for the actual transmission of the payload tothe loading station. Upon receipt of the request in step 506, theloading station initiates the transmission of the payload in step 507.Additionally, in step 507 destination information may be transmittedindicating to the mobile terminal where to store the received data. Inanother embodiment of the invention, the mobile terminal may not send arequest. In this case, the loading station may, for example,automatically start transmitting the payload after a predetermined timeafter sending the header. If the header has not been verifiedsuccessfully, the mobile station may simply discard the payload uponreceipt, thereby avoiding storing invalid data/software and potentiallyoverwriting existing data/software. However, in a preferred embodiment,the transmission of the payload is triggered by a request from themobile terminal, thereby avoiding unnecessary transmissions. Uponreceipt of the payload (step 509), the mobile terminal verifies thepayload in subsequent step 510. This verification step may comprise theverification of a cryptographic checksum calculated over the header andthe payload or another cryptographic method for verifying theauthenticity and/or integrity of the received data. If the payload isverified successfully, in step 510 the payload may be further processed,e.g. uncompressed, and stored in the target storage area as indicated bythe received destination information. Furthermore, an acknowledgment maybe sent to the loading station informing the loading station, that thepayload is received successfully. Hence, when the loading station hasreceived this receipt in step 512, the loading process is completed.Alternatively, the mobile terminal may not return an acknowledgement.For example, a message may be displayed on the display of the mobileterminal instead, thereby indicating to a user that the loading processis completed.

Especially if the payload includes software, it is particularlyadvantageous that the received payload is processed, e.g. uncompressed,only after it is verified, because this ensures that the software is notstored in an executable form until it is verified. This is even moreadvantageous, if the same storage area is used both as intermediatestorage prior to the verification and as a final storage area from whichthe executable software subsequently is loaded for execution. Forexample, the received software may be stored unprocessed in flashmemory, subsequently loaded from flash memory for verification andprocessing. Upon successful verification, the relevant blocks of flashmemory may be erased, and the verified software may be processed intothe same blocks of flash memory, but now in executable form.

FIG. 6 shows a block diagram of a system for loading data into a mobileterminal and the corresponding security functionality according to anembodiment of the invention. The system comprises a loading station 101and a mobile terminal 105, e.g. a mobile terminal as described inconnection with FIG. 2. The mobile terminal comprises a processing unit107 which provides functionality 610 for calculating a message digest ofheader data and payload data which is received from the loading stationvia the communications unit 106. The processing unit 107 furtherprovides functionality 611 for extracting and decrypting a cryptographicchecksum from the received header and the received payload data,resulting in respective decrypted message digests. The decryption may beperformed using, for example, an RSA algorithm and on the basis of apublic key stored in a section 614 of the storage medium 108 of themobile terminal. Furthermore, the processing unit 107 providesfunctionality 612 for comparing the calculated and the decrypted messagedigests in order to verify the authenticity and integrity of thereceived header/payload. If the calculated message digest and thedecrypted message digest are not the same, the received header/data maydiffer from the original header/data, or the header/data was not signedwith a private key corresponding to the public key used for decryption.Hence, the received header/payload is rejected. If the header isverified successfully, the processing unit 107 causes a message to bereturned to the loading station requesting transmission of the payload.Finally, the processing unit provides functionality 613 for the furtherprocessing of the received payload, such as decompression and storing ina corresponding section 615 of the storage 108. The above functionalitymay be implemented in software or, alternatively, the described featuresmay be implemented by hardwired circuitry instead of software or incombination with software. The loading station 101 comprises a base unit601, e.g. a suitably programmed personal computer, or another suitabledevice and an encryption module 604. The base unit comprises memory 603for storing the payload data, e.g. software, to be loaded into themobile terminal, and a communications circuit 102 for communicating thedata with the mobile terminal, e.g. as described in connection withFIG. 1. The base unit 601 further comprises a processing unit 602providing functionality 609 for generating a header for the storedpayload data, and functionality 608 for calculating one or more messagedigests over the payload and the corresponding header. The encryptionmodule 604 comprises a processing unit 606 for encrypting the calculatedmessage digest(s) based on a private key stored in a secure memory 605of the encryption module, e.g. using an RSA algorithm or anothersuitable cryptographic method. The processing unit 602 of the base unit601 further provides functionality 607 for controlling the transmissionof the resulting header and payload to the mobile terminal via thecommunications circuit 102 of the base unit. In one embodiment, theencryption unit is implemented as a smart card, and the base unit 601 isequipped with a card reader. Alternatively, another interface betweenthe encryption unit and the base unit may be used. It is an advantage ofthis embodiment that a loading station may easily be configured with anew private key, and the private key is securely stored in theencryption unit.

It is noted that different modular embodiments of the loading stationsmay be used. For example, the encryption unit may also calculate themessage digest.

FIGS. 7 a-c illustrate examples of data formats according to anembodiment of the invention. In the examples of FIGS. 7 a-c, the payloaddata comprises software to be loaded into the flash memory of a mobileterminal. As mentioned above, flash memory is a type ofconstantly-powered nonvolatile memory that can be erased andreprogrammed in units of memory called blocks. It is a variation ofelectrically erasable programmable read-only memory (EEPROM). However,while EEPROM is erased and rewritten at the byte level, the flash memorycan be written to in block sizes, making it easy to update. For examplea block may be 64 kbyte large. The payload 302 in FIGS. 7 a-c is dividedin N blocks P₁, P₂, . . . , P_(N) of equal size corresponding to theblock size of the flash memory of the mobile terminal. Each block isprefixed by a destination information D₁, D₂, . . . , D_(N), indicatingthe block addresses of the target blocks in flash memory where thereceived payload blocks should be stored. The destination informationmay comprise block numbers or addresses. In case of consecutive blocks,only the starting address of the first block P₁ is necessary. In thiscase, D₁ may provide the start address and the remaining D_(i)'s may beset to zero or be omitted. Preferably, the header information comprisesan indication as to how the mobile terminal should interpret thedestination list. In an alternative embodiment, the destinationinformation may be included in the header, thereby ensuring that thedestination information is verified cryptographically prior to loadingthe data to that destination. This may be particularly advantageous, ifthe payload comprises software which is to be loaded into IRAM, in orderto avoid an unauthorised overwriting of existing software. If the sizeof the payload data is not a multiple of the block size, the data may bepadded, e.g. with zeros. Now referring to FIG. 7 a, the header section301 comprises a manufacturer-related header section 301 a with acorresponding header cryptographic checksum 301 b comprising acalculated an encrypted message digest over the header information 301a, i.e. CCS_(H)=RSA_(k1)(SHA1(H_(M))), i.e. a message digest of theheader section 301 a computed according to the Secure Hash Algorithm(SHA-1) and encrypted using an RSA algorithm with a private key k1 ofthe loading station, preferably the private key of the manufacturer. Inone embodiment, the message digest MD_(H)=SHA1(H_(M)) is padded in orderto achieve an appropriate length for the RSA operation, i.e.CCS_(H)=RSA_(k1)(SHA1(H_(M))|padding), where ‘|’ symbolisesconcatenation of bit strings. The padding may be performed according toany suitable padding scheme, e.g. PKCS#1 padding. In one embodiment, theheader cryptographic checksum is further calculated over the public keyto be used for decrypting the payload message digests at the mobileterminal. The header information in 301 a may comprise information whichis related to the type of mobile terminal and independent of the actualcontent of the payload. The header 301 further comprises apayload-related header 301 c comprising information such as softwareversion, a specification of compatible execution environments, a commandsection indicating parameters used by the mobile terminal during theprocessing of the payload. For example, the information may comprise thenumber N of payload blocks, and information about whether the payloadblocks correspond to a sequence of consecutive blocks or whether theyare individual, scattered blocks. The parameters may further compriseinformation about whether and what type of compression and/or encryptionis used, the length of the payload, etc. Finally, the header comprises acryptographic checksum 301 d including an encrypted list of a messagedigest MD_(PL) of the payload header and N payload message digests, i.e.CCS_(PL)=RSA_(k2)(MD_(PL)|MD₁|MD₂| . . . |MD_(N)), each message digestMD₁, MD₂, . . . , MD_(N) being related to a corresponding one of theblocks P₁, . . . , P_(N). The list is encrypted using the softwareprovider's private key k2. In one embodiment, MD₁ is calculated over theheader sections 301 a-c, the destination information D₁, and the firstpayload block P₁, i.e. MD₁=SHA1(H_(M)|CCS_(H)|H_(PL)|D₁|P₁), where ‘|’symbolises concatenation of bit strings. The remaining message digests,i.e. MD₂, . . . , MD_(N) are calculated accordingly, i.e.MD _(i) =SHA1(H _(M) |CCS _(H) |H _(PL) |D ₁ |P ₁ | . . . |D _(i) |P_(i)), i=2, . . . , N.

It is noted that alternatively to using different private keys for thecalculation of CCS_(H) and the block cryptographic checksums,respectively, the same private key may be used. For example, if theentire header information 301 is generated by one authority, the privatekey of that authority may be used.

It is further noted that the message digests MD₁, . . . , MD_(N-1) maybe truncated, e.g. to one byte, in order to reduce the size of theheader. This implies that the probability to succeed with an attempt toinsert a false block increases, e.g. to a probability of {fraction(1/16)} in the case of a truncation to one byte. However, such amodification would be noticed during the final check of MD_(N).

Now referring to FIG. 7 b, the data format comprises a header section301, and a payload section 302 with N blocks of payload data asdescribed above. Furthermore, the data format comprises a section 703including a list of truncated block message digests MD₁*, . . . ,MD_(N-1)* of the payload blocks P₁, . . . , P_(N-1). As described above,the message digests may be calculated according toMD _(i) =SHA1(H _(M) |CCS _(H) |H _(PL) |D ₁ |P ₁ | . . . |D _(i) |P_(i)), i=1, . . . , N−1.

Preferably, the block message digests are truncated to 1 byte, asdescribed in connection with FIG. 7 a and as indicated by the asterix‘*’. The header section 301 comprises a manufacturer-related headersection 301 a with a corresponding header cryptographic checksum 301 bas described in connection with FIG. 7 a. The header 301 furthercomprises a payload-related header 301 c as described in connection withFIG. 7 a. Finally, the header comprises a cryptographic checksum 301 eincluding an encrypted list of a message digest MD_(PL) of the payloadheader 301 b, the full block message digest MD_(N) of the last payloadblock P_(N), and a message digest MD_(L) of the list of message digests302, i.e. CCS_(PL)=RSA_(k2)(M_(PL)|MD_(N)|MD_(L)). For example, each ofthe message digests may include 20 bytes. The list is encrypted usingthe software provider's private key k2. In particular, the non-truncatedblock message digest MD_(N) allows a secure final verification of thereceived data even though the previous block message digests MD₁*, . . ., MD_(N-1)* are truncated.

It is an advantage of this embodiment that only the message digestMD_(L) of the list 302 and the message digest MD_(N) need to beencrypted rather than all the block message digests MD₁*, . . . ,MD_(N-1)*, thereby reducing the size of the message significantly. Thisis a particular advantage for large number of blocks N.

Now referring to FIG. 7 c, instead of including the block cryptographicchecksum of the list of message digests in the header, the encryptedmessage digests CCS_(i=RSA) _(k2)(MD_(i)) may be prefixed the individualblocks. However, it is an advantage of the embodiments of FIGS. 7 a-b,that only one decryption step needs to be performed in order to retrievethe message digests, thereby reducing the computational requirements.According to this embodiment, the header comprises a header section 301f including both the manufacturer-related information and thepayload-related information. Accordingly, the corresponding headercryptographic checksum 301 g is calculated over the header section 301f.

FIGS. 8 a-c show flow diagrams of examples of a method of loading datainto a mobile terminal according to embodiments of the inventioncorresponding to the data formats of FIGS. 7 a-b, respectively.Referring to FIG. 8 a, in the initial step 800, the loading station 101compresses the payload and generates the header information, e.g. theheader information described in connection with FIG. 7 a. In anotherembodiment, the payload may be compressed by the payload provider andreceived by the loading station in compressed form. In step 801 acommunications link is established with the mobile terminal 105, and theheader 301 is sent to the mobile terminal using a suitable protocol. Themobile terminal receives the header information in step 802 and extractsthe individual header sections 301 a-301 d of FIG. 7 a, i.e. the data ofH_(M) and CCS_(H), H_(PL), and the encrypted list CCS_(PL) of messagedigests MD_(PL),MD₁, . . . ,MD_(N). The received CCS_(PL) is decryptedusing the corresponding public key stored in the mobile terminal and themessage digests of the payload header and the block message digests MD₁,. . . ,MD_(N) are retrieved. Furthermore, the mobile terminal verifiesthe header information. This verification may comprise a number ofdifferent checks, for example:

-   -   The header message digest is calculated over the received header        information and the CCS_(H) included in the header is extracted        and decrypted with the corresponding public key stored in the        mobile terminal. If the two values are the same, the header is        accepted as valid and originating from a trusted source.    -   The message digest MD_(PL) is verified.    -   Additional parameters, such as type of chip set, type of mobile        terminal, etc. are compared to the actual execution environment        of the mobile terminal.

If the verification fails, the loading process is aborted. If theverification succeeds, in step 804 an acknowledgment is sent from themobile terminal to the loading station acknowledging the receipt of theheader. In another embodiment, the mobile terminal may send a requestfor receiving the payload to the loading station. It is noted that in analternative embodiment the header may be transmitted and verified as twoor more messages. For example, the header sections 301 a-b comprisingthe manufacturer header may initially be transmitted. After verificationof this information, the payload header 301 c-d may be transmitted andverified. Upon receipt of the acknowledgment (step 805), in step 806 theloading station initiates sending the blocks P_(i), i=1, . . . , N ofpayload data, each prefixed by the corresponding destination informationD_(i): Initially a counter is set to i=1. In step 807, the block P_(i)and the destination information D_(i) are transmitted from the loadingstation to the mobile terminal. In step 808, the mobile terminalreceives the block P_(i) and the destination information D_(i) and loadsthem into RAM. The corresponding MD_(i), as extracted from the headerinformation, is already available in RAM. In step 809, the block messagedigest MD_(i) is checked. Hence, the message digest is calculatedcorresponding to the calculation in the loading station, i.e. in theexample of FIG. 7 a asMD _(i) =SHA1(H _(M) |CCS _(H) |H _(PL) |D ₁ |P ₁ | . . . |D _(i) |P_(i)), for i=1, . . , N.

Subsequently, the calculated and decrypted values of MD_(i) are comparedwith each other. If they differ, the block is rejected and, in step 810,a retransmission is requested, unless a predetermined maximum number ofallowed retransmissions is exceeded. In this case, the loading processis aborted.

If the message digests are equal, the block P_(i) is decompressed andstored in a block of flash memory as indicated by the destinationinformation D_(i). If the current block is not the final block, i.e.i<N, in step 812, the successful loading of block Pi is acknowledged bysending a corresponding request for the next block to the mobileterminal. Upon receipt of the request (step 813), the loading stationincrements a corresponding counter (step 814) and iterates bytransmitting the next block, starting with step 807. When the last blockP_(N) is loaded successfully, in step 816 a final acknowledgment is sentto the loading station. Upon receipt of the final acknowledgement (step817), the loading station completes the loading process.

Now referring to FIG. 8 b, as described above, the loading station 101compresses the payload and generates the header information in step 800,e.g. the header information described in connection with FIG. 7 b. Inanother embodiment, the payload may be compressed by the payloadprovider and received by the loading station in compressed form. In step801 a communications link is established with the mobile terminal 105,and the header 301 is sent to the mobile terminal using a suitableprotocol. The mobile terminal receives the header information in step802 and extracts the individual header sections 301 a-301 c, and 301 eof FIG. 7 b. The header message digest is calculated over the receivedheader information H_(M), and the calculated message digest is comparedwith the corresponding value extracted by decrypting the receivedCCS_(H). If the two values are the same, the header is accepted as validand originating from a trusted source. Furthermore, the receivedCCS_(PL) is decrypted using the corresponding public key stored in themobile terminal and the message digests MD_(PL), MD_(N), and MD_(L) areretrieved. The MD_(PL) may be used to verify the payload header H_(PL)301 c, while the remaining two message digests are stored in RAM forlater use. Furthermore, the mobile terminal may further verify theheader information as described above. If the verification fails, theloading process is aborted. If the verification succeeds, in step 804 anacknowledgment is sent from the mobile terminal to the loading stationacknowledging the receipt of the header. Upon receipt of theacknowledgment (step 805), in step 820 the loading station initiatessending the list 703 of truncated block message digests MD₁*, . . . ,MD_(N-1)*. Upon receipt of this list, in step 821, the mobile terminalverifies the received list by calculating the corresponding messagedigest and comparing the result with the previously received value ofMD_(L). If they differ, the list is rejected and, in step 822, aretransmission is requested, unless a predetermined maximum number ofallowed retransmissions is exceeded. In this case, the loading processis aborted. If the list is verified successfully, in step 823 anacknowledgement is sent to the loading station. Upon receipt of theacknowledgment (step 824), in step 807 the loading station initiatessending the blocks P_(i), i=1, . . . , N of payload data, each prefixedby the corresponding destination information D_(i): Initially a counteris set to i=1. In step 807, the block P_(i) and the destinationinformation D_(i) are transmitted from the loading station to the mobileterminal. In step 808, the mobile terminal receives the block P_(i) andthe destination information D_(i) and loads them into RAM. Thecorresponding MD_(i)*, as extracted from the received list, is alreadyavailable in RAM. In step 809, the block message digest is checked.Hence, the message digest is calculated corresponding to the calculationin the loading station, and the truncated bits of MD_(i)* are comparedwith the corresponding bits of the calculated message digest. If theydiffer, the block is rejected and, in step 810, a retransmission isrequested, unless a predetermined maximum number of allowedretransmissions is exceeded. In this case, the loading process isaborted. If the truncated message digests are equal, the block P_(i) isdecompressed and stored in a block of flash memory as indicated by thedestination information D_(i). If the current block is not the finalblock, i.e. i<N, in step 812, the successful loading of block P_(i) isacknowledged by sending a corresponding request for the next block tothe mobile terminal. Upon receipt of the request (step 813), the loadingstation increments a corresponding counter (step 814) and iterates bytransmitting the next block, starting with step 807. If the currentblock is the final block P_(N), the step 809 of checking the blockmessage digest involves calculating the corresponding message digest,e.g. according toMD _(N) =SHA1(H _(M) |CCS _(H) |H _(PL) |D ₁ |P ₁ | . . . |D _(N) |P_(N)).

In this case, the calculated message digest is compared with the valueMD_(N) which was received as part of the header information and which,preferably, was not truncated. Consequently, as the calculation ofMD_(N) involves all previous payload blocks, a previous erroneousacceptance of one of the blocks P1, . . . , PN-1 due to the truncationof the message digests MD₁*, . . . , MD_(N-1)*, may be detected at thispoint. When the last block P_(N) is loaded successfully, in step 816 afinal acknowledgment is sent to the loading station. Upon receipt of thefinal acknowledgement (step 817), the loading station completes theloading process.

Alternatively, the destination information and payload message digestsmay be transmitted in connection with the individual blocks rather thanas part of the initial header. This corresponds to the data format ofthe example of FIG. 7 c.

It is an advantage of the embodiments of FIGS. 8 a-b that each block ofreceived payload data only needs to be flashed once, i.e. aftersuccessful verification and after possible further processing, therebyincreasing the efficiency of the method. Furthermore, each block offlash memory is only written to, if the new data is verified, therebyavoiding overwriting previous data with an invalid update.

It is further noted that other methods of calculating a cryptographicchecksum, a message digest, or the like, may be employed, such as MD-4,MD-5, or other technologies, such as cyclic redundancy check, etc.

In one embodiment, the keys used for encryption of the header messagedigest and the block message digests are different keys of ahierarchical trust chain according to which authorities control thedifferent header information and the payload. For example, according tothe example of FIG. 4, the root key 401 may be used to decrypt theheader cryptographic checksum, while the public key 402 may be used todecrypt the block message digests.

It is an advantage of this embodiment that it allows a differentialupdate of existing software or other payload. For example, if an updatedsoftware version differs from the older version in some of the memoryblocks, the above method allows the loading to be limited to the loadingof the affected blocks, which are flashed in the corresponding memoryblocks as dictated by the destination information D_(i). The generationof a patch comprising the changed blocks may be a part of the processingperformed by the loading station before transmitting the header. Thisprocessing may be based on information received from the mobile station.

Furthermore, the download may be limited to patches which are actuallyrequired. The compression algorithm used may be optimised for patches,thereby reducing the amount of data. Patches are typically scatteredchanges in the software. Hence, the software update may be representedas a bit string where zeros indicate no changes and ones indicatechanges. In this representation, a typical patch update corresponds toan almost zero string. A compression algorithm used for the softwareupdate string may thus be optimised for this type of informationstrings, thereby yielding a very efficient method of downloadingsoftware patches.

1. A method of loading data into a mobile terminal (105), the methodcomprising the steps of receiving the data from a loading station (101)by the mobile terminal, the data comprising payload data (302) andheader data (301); and accepting the data by the mobile terminalconditioned on a verification process based on the header data;characterised in that the step of receiving the data further comprisesthe steps of receiving (503, 802) a header message including the headerdata from the loading station by the mobile terminal; verifying (504,802) the received header data by the mobile terminal; receiving (508,808) at least a first payload message including the payload data, if theheader data is verified successfully.
 2. A method according to claim 1,characterised in that the header data comprises a first cryptographicdata item (303 a, 301 b, 301 d, 301 e) and the step of accepting thedata by the mobile terminal comprises the step of performing acryptographic verification process based on the first cryptographic dataitem.
 3. A method according to claim 1 or 2, characterised in that thepayload data is divided into a number of blocks of payload data (P₁, . .. , P_(N)), and the step of receiving the payload data further comprisesthe steps of receiving a number of payload messages each comprising oneof the blocks of payload data; and storing in a storage medium each ofthe received number of blocks of payload data.
 4. A method according toclaim 2, characterised in that the payload data is divided into a numberof blocks of payload data (P₁, . . . , P_(N)); the method furthercomprises the step (821) of receiving a corresponding number of messagedigests (703) related to respective ones of the number of blocks ofpayload data; the step of receiving the payload data further comprisesthe step of receiving a number of payload messages each including one ofthe number of blocks of payload data; and the step of accepting the databy the mobile terminal further comprises, for each of the number ofblocks of payload data, the steps of accepting the block of payload databy the mobile terminal conditioned on a cryptographic verificationprocess based on a corresponding one of the message is digests;processing the accepted block of payload data; storing the processedblock of payload data in a storage medium.
 5. A method according toclaim 4, characterised in that the cryptographic verification processused in the step of accepting a first block of payload data receivedafter a second block of payload data is further based on a result of acryptographic verification process used in a previous step of acceptingthe second block of payload data.
 6. A method according to any one ofclaims 3 through 5, characterised in that the storage medium is dividedinto a number of storage blocks each having a predetermined size; andeach of the number of blocks of payload data have a block sizecorresponding to the size of storage blocks.
 7. A method according toclaim 6, characterised in that the payload data comprises an update ofexisting data loaded in the mobile terminal; and the method furthercomprises the step of only loading the blocks of payload data whichdiffer from a corresponding block of the existing data.
 8. A methodaccording to any one claims 2 through 7, characterised in that the firstcryptographic data item includes a first message digest encrypted with aprivate key of an authority; and the step of accepting the data by themobile terminal comprises the steps of calculating a second messagedigest of the received header data and the received payload data;decrypting the first message digest with a public key of said authority;and comparing the decrypted first message digest with the calculatedsecond message digest.
 9. A method according to any one of claims 2through 8, characterised in that the header data further comprises asigned key to be used in the verification process by the mobile terminalas a public key of the authority distributing the payload data.
 10. Amethod according to any one of claims 1 through 9, characterised in thatthe header data further comprises a second cryptographic data item, andthe step of verifying the header data comprises the step of performing acryptographic verification of the header data based on the secondcryptographic data item.
 11. A method according to any one of claims 1through 10, characterised in that the method further comprises the stepof processing the payload data conditioned on the step of accepting thedata by the mobile terminal.
 12. A method according to claim 11,characterised in that the payload data is received in a compressed form;and the step of processing comprises the step of decompressing thepayload data.
 13. A method according to any one of claims 1 through 12,characterised in that the method further comprises the step of sending arequest for receiving the payload data to the loading stationconditioned on a result of the step of verifying the header data.
 14. Amethod according to any one of claims 1 through 13, characterised inthat the payload data comprises program code means.
 15. A methodaccording to any one of claims 1 through 14, characterised in that thepayload data comprises a software patch.
 16. A method of uploading datainto a mobile terminal (105), the method comprising the step oftransmitting the data by a loading station (101) to the mobile terminal,the data comprising payload data (302) and header data (301) for use bythe mobile terminal in a verification process when accepting the data;characterised in that the step of transmitting the data furthercomprises the step (502, 801) of transmitting a header message includingthe header data to be verified by the mobile terminal beforetransmitting (507, 807) at least a first payload message including thepayload data, allowing the mobile terminal to reject reception of thepayload data.
 17. A method according to claim 16, characterised in thatthe method further comprises the steps of receiving a request from themobile terminal for transmitting the payload data; and transmitting thepayload data to the mobile terminal in response to the received request.18. A method according to claim 16 or 17, characterised in that themethod further comprises the steps of processing the payload data to beuploaded into the mobile terminal; generating a cryptographic data itemfor the processed payload data; and transmitting the cryptographic dataitem as a part of the header data.
 19. A method according to any one ofthe claims 16 through 18, characterised in that the method furthercomprises the steps of dividing the payload data into a sequence ofblocks of payload data, each having a predetermined size correspondingto a block size of a memory of the mobile terminal where the payloaddata is to be stored; and transmitting a number of payload messages eachincluding one of the number of blocks of payload data.
 20. A methodaccording to claim 19, characterised in that the method furthercomprises the steps of generating a sequence of message digests, eachmessage digest being related to a corresponding one of the number ofblocks of payload data; and transmitting the sequence of message digests21. A method according to claim 19 or 20, characterised in that thepayload data comprises an update of existing data loaded in the mobileterminal; and the method further comprises the step of only transmittingblocks of payload data which differ from a corresponding block of theexisting data.
 22. A system for loading data into a mobile terminal(105), the system comprising a loading station (101) and the mobileterminal the loading station including first transmitting means (102)for transmitting data to the mobile terminal, the data comprisingpayload data (302) and header data (301); the mobile terminal includingfirst receiving means (106) for receiving said data from the loadingstation; and processing means (107) adapted to accept the dataconditioned on a verification process based on the header data;characterised in that the loading station is adapted to transmit aheader message including the header data before transmitting the payloaddata; the mobile terminal is adapted to receive the header message fromthe loading station, to verify the received header data and to cause thefirst receiving means to receive the payload data, if the header data isverified successfully.
 23. A mobile terminal (105) comprising receivingmeans (106) for receiving data from a loading station (101), the datacomprising payload data (302) and header data (301); and processingmeans (107) adapted to accept the received data conditioned on averification process based on the header data; characterised in that thereceiving means is further adapted to receive a header message includingthe header data from the loading station; and the processing means isfurther adapted to verify the received header data; and to cause thereceiving means to receive the payload data if the header data isverified successfully.
 24. A loading station (101) for uploading datainto a mobile terminal (105), the loading station comprisingtransmitting means (102) for transmitting data to the mobile terminal,the data comprising payload data (302) and header data (301) for use bythe mobile terminal in a verification process when accepting the data;characterised in that the transmitting means is further adapted totransmit a header message including the header data to be verified bythe mobile terminal before transmitting the payload data, allowing themobile terminal to reject reception of the payload data.
 25. A loadingstation according to claim 24, characterised in that the loading stationcomprises a first device (604) including a secure memory (603) forstoring a private key, and second processing means (606) for generatinga cryptographic data item; and a second device (601) comprising secondprocessing means (602) for generating the header data including thegenerated cryptographic data item.
 26. A loading station according toclaim 25, characterised in that the first device is a smart card.
 27. Acomputer program comprising program code means adapted to, when executedin a mobile terminal, perform the steps of the method according to anyone of the claims 1 through
 15. 28. A computer program according toclaim 27, characterised in that the computer program is embodied on acomputer-readable medium.
 29. A computer program according to claim 27,characterised in that the computer program is embodied as a data signalon a carrier wave.
 30. A computer program comprising program code meansadapted to, when executed in a loading station, perform the steps of themethod according to any one of the claims 16 through
 21. 31. A computerprogram according to claim 30, characterised in that the computerprogram is embodied on a computer-readable medium.
 32. A computerprogram according to claim 30, characterised in that the computerprogram is embodied as a data signal on a carrier wave.